新增單筆資料, <10ms 叫正常, >100ms叫不正常, >1000ms(1s)叫異常
查詢單筆資料, <100ms 叫正常, >1000ms(1s)叫不正常, >10s 叫異常
解決一個AP Server 卡卡問題, 原因是要深入DB調校新增大量上傳LOG; 其實系統許多問題不在AP Server , 而是在 DB Server , 首先要決定什麼叫異常現象, 例如新增單筆資料>100ms叫不正常, >1000ms(1s)叫異常, 再由異常現象去推敲原因;很多時候系統出問題時, 是處理人員連什麼叫異常都不知道.
了解了什麼是異常狀況之後
那該怎麼解決呢?? 
解決問題的第一步通常是先要確認那些是異常現象, 需要處理那些異常現象...
接下來推敲原因, 可找書或找文件, 找MS SQL ONLONE BOOK, 問孤狗大師.....
看是要調整索引,改寫SQL, 變更設定, 或加個暫存或資料檔案(或記錄檔)...
通常問題應可當天解決, 若需調整較大時需向使用者要維護時間~~
不同種類的DB Server有不同的調校方法
你這篇的心得
真的看不出對其他人有何用處?
能否舉例一下
問題與解法
或許還比較有用吧
查詢單筆資料會慢
大多是巨量資料
沒對搜尋用的篩選條件的欄位做索引
或是濫用全文搜尋
至於新增單筆資料
通常不太可能會慢
但如果新增資料時, 是有從Table去Select的話, 那一樣會發生上述問題
查詢單筆資料會慢
另一個可能原因是
關聯的Table串太多個
這時候可以參考反正規化的作法
預先將欄位展開
以增加查詢時的效率
正規化與反正規化各有利弊
所以要看情況用
如果是跨DB Server的查詢
也會變慢
這時用在同一台DB Server裡預先建立遠端DB Server的Table的鏡像備份
當做快取來源
也能夠大幅改善查詢效能
只是問題在於要多久同步化一次
至於海量資料的查詢的作法
則與上述相反
資料預先打散到多台的DB Server去
查詢時, 再根據搜尋條件再決定到那一台DB Server去抓資料
新增資料時, 也是根據關鍵欄位,去決定到那一台DB Server新增資料
謝謝大大的指教...
對資料庫見解深入.....
無論是在查詢單筆資料或是新增單筆資料,
看法蠻有經驗及條理;
我要補充一點是....
要多思考資枓在資料庫內的物理排序(包含表格及索引)...
資料庫調校...只從Log來看是無法提出解決方法的, 還要從Execution Plan來著手, 找出造成瓶頸的SQL, 研究該SQL的Cost何在, 然後, 才能真正解決問題.
但依我個人的看法...應該從下列幾個步驟去探討...
謝謝大大分享...
其實這篇分享最主要是透過SQL執行時間,
去確認出異常的現象....
至於調校手法....也是要確認出那些異常現象後, 再去調校....
否則連異常問題在那兒都不知, 調校往往是漫無目的...
charmmih 兄，先與你說聲對不住．．．
前天真是手賤，一不小心，就把回覆給刪了...抱歉抱歉！！...
其實我同你們一樣，都是一般的打字工人而已，被稱大大，真承擔不起...
致於【指教】，那就更不敢當啦，只是同好，大家一同研究研究倒是真的..
我從你所貼上的追蹤判斷你寫程式的方式，應該是使用微微軟它的資料庫
元件，就是那種拖拖拉拉的【Data Environment】資料庫元件作為與資料
庫溝通的工具，熟悉網路作業系統的人員都會知道，它是最沒有效率的元
件，原因我就不多說了...
使用這種元作寫出來的程式，資料庫就不用太調校，因為它已是系統最佳
搭配狀態，所以，再怎麼調，都是一樣，只會讓你的資料庫更不穩定，不
會有更好的狀況滴...
不再使用微軟開發系統的【Data Environment】資料庫元件，應該是唯一
的方法，或許你可能會說，怎麼可能，程式已寫了這麼多，放棄使用它，
不就等於所有程式都要重寫了嗎？
請不再誤會我的意思，我的說法是，新程式不要再用了，而不是回頭去改
你已穩定在服役中的程式．．．
致於要用什麼方法寫呢，我會介紹你到MSDN技術網去查詢，那裡有很多種
方法，當然也包括你現在用的這種方法．．
降低你在資料庫溝通時所耗的資源，資料庫的效能自然就提升了，其實不
管是微軟的SQL Server或是Oracle DataBase， 它們在安裝完成後的內定
設定值，對於效能都非常的優，而且保證穩定，任意的改變設定值以提升
效能，雖然可能會得到更好的效率，但有可能會犧牲穩定性，這在資料庫
的系統手冊裡是有說明到的，所以請勿輕忽．．
資料庫的內定值，本就是很好的設定值，剩下的問題就是寫程式人員的觀
念及寫法而已，用對了方法，你可讓資料庫有更多的處理資料空間，如妥
善的分配前後端各做什麼事，以有效的發揮所有電腦的運算功能。
資料庫的規畫更是重要，妥善的運用資料庫的內定資源，如索引的規劃，
何時該用叢集索引、何時不該用叢集索引；資料參照優於資料觸發的使用
；資料庫正規化的配置是否洽當等等．．．
總之，提升資料庫效能應從程式規劃著手，ＳＡ的角色很重要，從資料庫
的系統設定去調校，只是消極的手段，規劃著手才是長遠而積極的手段．．
最後祝你成功．．
這只不過是SQL Server 的 SQL Profilier 錄出來的SQL 執行效能欄位(cpu time, Logical READS, Physical Writes, Duration),用來表示每一段錄的SQL執行耗用多少CPU時間, 邏輯讀取, 實體寫入, 耗用時間; 再者這只不過資料庫工具在側錄一個JAVA系統中SQL執行狀況,當資庫庫需要監測時才開起來的工具.
使用這種元作寫出來的程式，資料庫就不用太調校，因為它已是系統最佳搭配狀態，所以，再怎麼調，都是一樣，只會讓你的資料庫更不穩定，不會有更好的狀況滴...
a. 不要再寫這種2266的看法, 會令人冷汗直流; 和資料庫有關的是直接進入資料庫的SQL, 比間接掛在AP Server 上的元件還重要; 無論是用那種元件, 進入資料庫的SQL是高耗時, 就是需要調校.
[quote]
其實不管是微軟的SQL Server或是Oracle DataBase， 它們在安裝完成後的內定設定值，對於效能都非常的優，而且保證穩定，任意的改變設定值以提升效能，雖然可能會得到更好的效率，但有可能會犧牲穩定性，這在資料庫的系統手冊裡是有說明到的，所以請勿輕忽．．
[quote]
a. 上述話是說給門外漢聽的, 使不深入瞭解系統參數意義的門外漢不要亂動系統參數; 再者, 系統內定預設值通常是給不大系統的設定值, 只要是負責的管理者, 對系統還是要深入瞭解系統參數的意義後再適當調整.
[quote]
總之，提升資料庫效能應從程式規劃著手，ＳＡ的角色很重要，從資料庫的系統設定去調校，只是消極的手段，規劃著手才是長遠而積極的手段．．
[quote]
a. SA 若沒有下功夫瞭解資料庫, 或有經驗的DBA 協助; 所規劃出來的系統也是2266; 至於用什麼手法去調校資料庫及系統, 只要經驗足夠則就可視實際狀況去評估, 是調資料庫參數設定, 調整資料或記錄檔案, 調整索引...等方式, 這方面沒有硬性限制.
這只不過是SQL Server 的 SQL Profilier 錄出來的SQL 執行效能欄位(cpu time, Logical READS, Physical Writes, Duration),用來表示每一段錄的SQL執行耗用多少CPU時間, 邏輯讀取, 實體寫入, 耗用時間; 再者這只不過資料庫工具在側錄一個JAVA系統中SQL執行狀況,當資庫庫需要監測時才開起來的工具.
使用這種元作寫出來的程式，資料庫就不用太調校，因為它已是系統最佳搭配狀態，所以，再怎麼調，都是一樣，只會讓你的資料庫更不穩定，不會有更好的狀況滴...
a. 確實元件在相關欄位填入後, 會自動產生完整SQL, 但是不要再寫這種2266的看法, 會令人冷汗直流; 和資料庫有關的是直接進入資料庫的SQL, 比間接掛在AP Server 上的元件還重要; 無論是用那種元件, 進入資料庫的SQL是高耗時, 就是需要調校.
其實不管是微軟的SQL Server或是Oracle DataBase， 它們在安裝完成後的內定設定值，對於效能都非常的優，而且保證穩定，任意的改變設定值以提升效能，雖然可能會得到更好的效率，但有可能會犧牲穩定性，這在資料庫的系統手冊裡是有說明到的，所以請勿輕忽．．
a. 確實在手冊上會有上述相關話語, 只是上述這段話是說給門外漢聽的, 使不深入瞭解系統參數意義的門外漢不要亂動系統參數; 再者, 系統內定預設值通常是給不大系統的設定值, 只要是負責的管理者, 對系統還是要深入瞭解系統參數的意義後再適當調整.
總之，提升資料庫效能應從程式規劃著手，ＳＡ的角色很重要，從資料庫的系統設定去調校，只是消極的手段，規劃著手才是長遠而積極的手段．．
a. 確實SA在系統效能上扮演重要的角色, 但是 SA 若沒有下功夫瞭解資料庫, 或有經驗的DBA 協助; 所規劃出來的系統在效能上也是2266; 至於用什麼手法去調校資料庫及系統, 只要經驗足夠則就可視實際狀況去評估, 是調資料庫參數設定, 調整資料或記錄檔案, 調整索引...等方式, 這方面沒有硬性限制.
iThome鐵人賽
看影片追技術